Design and prototyping of the SPECTRA simulator architecture

SPECTRA (Surface Processes and Ecosystem Changes through Response Analysis) is a planned spaceborne multiangular hyperspectral and thermal imaging spectrometer in phase A early design led by ESA’s earth observation group. Its mission is to describe, understand and model the role of terrestrial vegetation in the global carbon cycle and its response to climate variability. Even though the project has been terminated in November 2005, many results of the phase A studies are considered to be useful as input to future missions. The SPECTRA end-to-end simulator is intended to be used to test different aspects of the SPECTRA mission concept and for tuning the retrieval algorithms as well as assessing their performances. The intention of this ESA-commissioned study was not to build an actually working simulator, but to conceive an architecture for a simulator to be built during phase B of the SPECTRA design, as well as perform a limited validation of this architecture. The software architecture for the future SPECTRA end-to-end simulator has been designed to be modular, flexible and distributed. It consists of a central control unit with associated database, which is controlled and monitored via an internet-accessible web interface, and a flexible number of modules performing the actual calculations. The list of simulator modules currently includes but is not limited to state-of-the-art developments in radiative transfer (Onera), instrument modelling (ESA), atmospheric correction (Onera), and various level 2 algorithms (Alterra). Assimilation models and global carbon flux models are linked to the simulator via the SPECTRA field segment database (RSL and Princeton), for which a high level schema has been defined. The simulator structure has been validated using full end-to-end simulations from ground data to top-of-atmosphere, through the SPECTRA instrument simulator provided by industry, and back again. Test data from the Barrax field site are used for this purpose (University of Valencia). Posted at the Zurich Open Repository and Archive, University of Zurich ZORA URL: https://doi.org/10.5167/uzh-97043 Published Version Originally published at: Dangel, Stefan; Brazile, Jason; Kneubühler, Mathias; Itten, Klaus I; Petitcolin, François; Jia, Li; Miesch, Christophe; Gloor, M; Moreno, Jose F; Schaepman, Michael E; Carnicero, B; Rast, Michael (2005). Design and prototyping of the SPECTRA simulator architecture. In: 4th EARsel workshop on Imaging Spectroscopy, Warsaw, Poland, 27 April 2005 30 April 2005, 101-106. © EARSeL and Warsaw University, Warsaw 2005. Proceedings of 4th EARSeL Workshop on Imaging Spectroscopy. New quality in environmental studies. Zagajewski B., Sobczak M., Wrzesień M., (eds) DESIGN AND PROTOTYPING OF THE SPECTRA SIMULATOR ARCHITECTURE S. Dangel, J. Brazile, M. Kneubühler, K.I. Itten, F. Petitcolin, L. Jia, C. Miesch, M. Gloor, J. Moreno, M. Schaepman, B. Carnicero and M. Rast 1. Remote Sensing Laboratories (RSL), University of Zürich, Winterthurerstrasse 190, 8057 Zürich, Switzerland email: [email protected] 2. Netcetera AG, Zurich, Switzerland 3. ACRI-ST, Sophia-Antipolis, France 4. Alterra Green World Research, Wageningen, The Netherlands 5. ONERA/DOTA, Toulouse, France 6. Princeton University, USA 7. University of Valencia, Spain 8. Centre for Geo-Information, Wageningen UR, The Netherlands 9. ESA-ESTEC, Noordwijk, The Netherlands INTRODUCTION SPECTRA (Surface Processes and Ecosystem Changes through Response Analysis) is a planned spaceborne multiangular hyperspectral and thermal imaging spectrometer in phase A early design led by ESA's earth observation group. Its mission is to describe, understand and model the role of terrestrial vegetation in the global carbon cycle and its response to climate variability. Even though the project has been terminated in November 2005, many results of the phase A studies are considered to be useful as input to future missions. The SPECTRA end-to-end simulator is intended to be used to test different aspects of the SPECTRA mission concept and for tuning the retrieval algorithms as well as assessing their performances. The intention of this ESA-commissioned study was not to build an actually working simulator, but to conceive an architecture for a simulator to be built during phase B of the SPECTRA design, as well as perform a limited validation of this architecture. The software architecture for the future SPECTRA end-to-end simulator has been designed to be modular, flexible and distributed. It consists of a central control unit with associated database, which is controlled and monitored via an internet-accessible web interface, and a flexible number of modules performing the actual calculations. The list of simulator modules currently includes but is not limited to state-of-the-art developments in radiative transfer (Onera), instrument modelling (ESA), atmospheric correction (Onera), and various level 2 algorithms (Alterra). Assimilation models and global carbon flux models are linked to the simulator via the SPECTRA field segment database (RSL and Princeton), for which a high level schema has been defined. The simulator structure has been validated using full end-to-end simulations from ground data to top-of-atmosphere, through the SPECTRA instrument simulator provided by industry, and back again. Test data from the Barrax field site are used for this purpose (University of Valencia). SOFTWARE ARCHITECTURE A critical component of the proposed SPECTRA simulator is the architectural framework to support the simulator given both technical (e.g. high bandwidth) and non-technical (e.g. intellectual property protection) constraints. From the various requirements that apply to the simulator, modularity emerged as the most important one. The architecture consists of a central control unit with associated database and a configurable set of modules which do the actual calculations. Figure gives an overview of one possible realization of such a chain of modules and the currently used module naming convention. Module A and C refer to the forward and inverse models (of which currently only the RTM parts dubbed A2 and C2 have been implemented as working modules), Module B is © EARSeL and Warsaw University, Warsaw 2005. Proceedings of 4th EARSeL Workshop on Imaging Spectroscopy. New quality in environmental studies. Zagajewski B., Sobczak M., Wrzesień M., (eds) the instrument simulator (two implementations resulting from two independent industry studies (i)) and module D refers to the SPECTRA field segment (ii). Effort has been made to ensure that the upgrading (including versioning) or changing of modules and the addition of new ones is easy and flexible. In order to meet these requirements, each module is bracketed by two converters and a database is placed between converters as shown. Scientific data and simulator management data are kept in a centralized relational database management system to ensure repeatability and facilitate dynamic configuration and flexibility. The system allows for the remote execution of any module and is controlled and monitored via a web interface. Figure gives an overview of the top-level software architecture for the CCU and external modules (“slaves”). The simulator design report (iii) includes a full description of the simulator data model, which is designed to support management of the highly modular architecture, the simulations and the scientific datasets. Remote execution of modules is addressed with respect to security-related deployment issues, data exchange and format conversions. Other issues related to the development and the maintenance of the simulator are addressed as well. The proposed concept of a simulator framework with modular and distributed architecture has also been illustrated by a working demonstration prototype. The flexibility of this architecture allows it to be used for virtually any future simulator consisting of any number and kind of modules. Figure 1: Overview of modules, converters and databases Module B Implementation 1 Module B Module C Retrieval Algorithms Module C1 Module A Ground data Module A1 RTM Commanche Module A2 Module D Implementation 2 Module B RTM Cochise Module C2 Data Base AB Data Base BC Data Base C Data Base A Conv A2I